Use effects for indirect call expressions#8625
Open
stevenfontanella wants to merge 3 commits intomainfrom
Open
Use effects for indirect call expressions#8625stevenfontanella wants to merge 3 commits intomainfrom
stevenfontanella wants to merge 3 commits intomainfrom
Conversation
690ee8d to
75481a7
Compare
tlively
reviewed
Apr 20, 2026
189d543 to
2630eff
Compare
75481a7 to
36a4fb5
Compare
Member
Author
|
Seems like JJ + Github don't play well when I'm on a branch based on another branch that had a merge commit. Will fix this after merging the other branch. |
stevenfontanella
added a commit
that referenced
this pull request
Apr 24, 2026
When running in --closed-world, compute effects for indirect calls by unioning the effects of all potential functions of that type. In --closed-world, we assume that all references originate in our module, so the only possible functions that we don't know about are imports. Previously [we gave up on effects analysis](https://github.com/WebAssembly/binaryen/blob/29b2d42e8a748fbe1095696d58a52b7bf83e2253/src/passes/GlobalEffects.cpp#L83-L87) for indirect calls. Yields a very small byte count reduction in calcworker (3799354 - 3799297 = 57 bytes). Also shows no significant difference in Binaryen runtime: (0.1346069 -> 0.13375045 = <1% improvement, probably within noise). We expect more benefits after we're able to share indirect call effects with other passes, since currently they're only seen one layer up for callers of functions that indirectly call functions (see the newly-added tests for examples). Followups: * Share effect information per type with other passes besides just via Function::effects (#8625) * Exclude functions that don't have an address (i.e. functions that aren't the target of ref.func) from effect analysis () * Compute effects more precisely for exact + nullable/non-nullable references Part of #8615.
36a4fb5 to
e65a243
Compare
30a31e1 to
60665f3
Compare
60665f3 to
2156d99
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #8615. After #8609, we compute effects for indirect call expressions, but only reflect this in the call-site via the effects of the
Functionthat contains the indirect call. That let us reason about effects only one layer of indirection away, for example in the following module:If we know that an indirect call to $t can't possibly have any effects (e.g. its only potential target is a nop), we'd be able to optimize away
(call $a)but not the(call_ref)itself, since the effects only got stored in the effects of$a.This PR lets us reason about indirect call effects at the expression level within function bodies by adding a map from HeapType to effects
typeEffectsinwasm::Module. As a result we can completely optimize out thecall_refin the above example.